Mobile communication has become a necessary part of people's life. With the popularization of mobile communication applications, people's demand for voice and data transmission is higher. Especially, video data transmission requires a bandwidth much more than the bandwidth for voice data transmission. At present, the second generation mobile communication systems, typically Global System for Mobile Communication (GSM) and Code Division Multiple Access (CDMA), have reached their limits of transmission rate. Therefore, the third generation (3G) mobile communication systems with higher data transmission rates emerge as the demand requires.
The IP Multimedia Subsystem (IMS) is an Internet Protocol (IP) multimedia subsystem in a Wideband Code Division Multiple Access (WCDMA) network defined in the 3rd Generation Partnership Project (3GPP) R5/R6 standard as well as the target network for implementing packet-based voice and data transmission and providing unified multimedia services and applications in 3G mobile networks.
The IMS employs an IP packet domain as its bearer channel for control signaling and media transmission and employs the Session Initiation Protocol (SIP) as call control signaling, and thereby implements separation among service management, session control, and bearer access.
IMS standard is a new standard and is improved progressively. At present, considerations are mainly taken to a 3G network itself rather than interworking between a 3G network and a circuit domain network. How an IMS calling party listens to ring-back tone or voice announcement is not considered in the current IMS standard when an interworking call is terminated in a circuit domain network, such as a Public Switched Telephone Network (PSTN) or an Integrated Services Digital Network (ISDN), and an Address Complete Message (ACM) is sent from the circuit domain network.
A PSTN termination procedure in the current 3GPP standard is shown in FIG. 1. It may be seen from FIG. 1 that the Media Gateway Control Function (MGCF) does not open a media stream channel by means of the H.248 protocol for a bidirectional connection until the circuit domain network sends an Answer Message (ANM) (step 13). However, the MGCF performs no similar operation to open a media stream channel when the circuit domain network sends an ACM message.
However, as we know, in one aspect, in the circuit domain network, when the called party sends an ACM message, the called party may send signal tone or voice announcement that is triggered by other service applications to indicate call failure, e.g., “No disturbing” voice announcement (if the called party has activated “No disturbing” service), “Incoming Call Barring” voice announcement (if the called party has activated Blacklist or Whitelist service), etc., besides ring-back tone (including customized ring-back tone, i.e., Customized Ring-Back Tone (CRBT)). Apparently, as shown in the procedure in FIG. 1, the MGCF does not begin media stream interaction when it receives the ACM message, and, as a result, the IMS calling party is unable to hear these ring-back tone, signal tone, or voice announcement.
In the standard ITU-T Q.1912.5 “Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control Protocol or ISDN User Part”, the solution for translation of ACM message in interworking between SIP and ISDN User Part (ISUP) is provided. Applied in an IMS network, the solution is: when the MGCF receives the ACM message, it determines whether the Called Party′ Status Indicator in the message is “subscriber free”, and if the indicator is “subscriber free”, the MGCF will translate the ACM message into a 180 Ringing response message; otherwise the MGCF will translate the ACM message into a 183 Session Progress response message.
That solution determines whether the content sent from the circuit domain network is ring-back tone indicating successful call or signal tone or voice announcement indicating failed call according to different SIP response messages (180 and 183).
However, this solution is unable to be applied in the above IMS procedure, because:
As specified in the IMS standard, on receiving the INVITE message, the MGCF will perform a media negotiation process with the calling party in the Offer/Answer mode. As shown in FIG. 1 and FIG. 2 provided in the current 3GPP standard, it may be seen clearly that the process is completed before the MGCF receives the ACM message. However, as we know, as specified in SIP, after that process, the MGCF is unable to send a 183 Session Progress response message again (in FIG. 2, it may be seen clearly that the MGCF has sent a 183 Session Progress response message once the Offer/Answer mode is activated; therefore, it is unable to send a 183 Session Progress response message again when it receives the ACM message subsequently). Since the MGCF does not send an SIP response message to the calling party, even though the MGCF opens the media stream channel and the calling party may hear the signal tone or voice announcement indicating call failure, the call from the calling IMS network will be suspended (due to unknown condition in the called network) and thereby the call will enter into an incorrect signaling process, because the circuit domain network usually does not send another ANM message (due to the call failure).
In addition, as specified in the ITU-T Q.1912.5 standard, the 183 Session Progress response message may only encapsulate the ACM message in the SIP-I format; otherwise the ACM message may not be translated. However, as we know, there is no mandatory requirement for the SIP-I in the IMS standard. Actually, for the foresaid demand, it is enough to determine whether the called party is free by means of the 180 Ringing and 183 Session Progress messages, without the need of carrying the ACM message body in the 183 Session Progress message.